System and method for updating files through differential compression

ABSTRACT

A computer system identifies a first version of a file set of a plurality of files. The computer system identifies one or more file set changes from a second version of the file set to the first version of the file set. The file set changes include at least one of: one or more added files, one or more updated files, and one or more deleted files. A view of the first version is generated based on a view of the second version and the identified file set changes. A difference between the view of the first version and the view of the second version is generated based on the view of the file set changes. The difference is transferred to a destination having the second version. The destination is configured to generate the first version from the second version and the difference.

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 61/921,366, titled “System and Method for TransferringFiles through Differential Compression,” filed Dec. 27, 2013, which isincorporated by reference herein in its entirety.

FIELD OF THE INVENTION

The present application generally relates to network file transfer, inparticular, to system and method for transferring files throughdifferential compression.

BACKGROUND OF THE INVENTION

With the advent of big data, the problem of transferring massive amountsof data over the Internet has become even more challenging. Manyorganizations, e.g., global companies have urgent needs to move massivefiles from data center to data center or from headquarter toheadquarter, or upload large volume of files to the cloud. Examplesinclude file replication, disaster recovery, remote backup, file sharingand synchronizing, file distribution and publishing, and so on.Traditional file transfer technologies, such as File Transfer Protocol(FTP) and RSYNC, are facing challenges when carrying those tasks due tothe overwhelming volume of data traffic across the networkinfrastructure.

SUMMARY

The above deficiencies and other problems associated with theconventional approach of file transfer are reduced or eliminated by thepresent application disclosed below. In some embodiments, the presentapplication is implemented in a computer server that has one or moreprocessors, memory and one or more modules, programs or sets ofinstructions stored in the memory for performing multiple functions andcommunicating with one or more client devices (e.g., a computer or asmartphone) that has one or more processors, memory and one or moremodules, programs or sets of instructions stored in the memory forperforming multiple functions. Instructions for performing thesefunctions may be included in a computer program product configured forexecution by one or more processors.

A first aspect of the present application involves a method oftransferring a file set from a source to a destination using a computersystem. The computer system identifies a first version of a file set ofa plurality of files. The computer system identifies one or more fileset changes from a second version of the file set to the first versionof the file set. The file set changes include at least one of: one ormore added files, one or more updated files, and one or more deletedfiles. A view of the first version is generated based on a view of thesecond version and the identified file set changes. A difference betweenthe view of the first version and the view of the second version isgenerated based on the view of the file set changes. The difference istransferred to a destination having the second version. The destinationis configured to generate the first version from the second version andthe difference.

A second aspect of the present application involves a method oftransferring a file set from a source to a destination using a computersystem. The computer system identifies a first file set of a firstplurality of files. The computer system generates a first view of thefirst file set and receives, from a destination, a second view of asecond file set of a second plurality of files. The computer systemgenerates a difference based on the first view, the second view, and thefirst file set and transfers the difference to the destination, which isconfigured to generate the first file set from the second file set andthe difference.

A third aspect of the present application involves a method oftransferring a file set from a source to a destination using a computersystem. The computer system identifies a first file set of a firstplurality of files and a second file set of a second plurality of filesand generates a first view of the first file set and a second view ofthe second file set. After generating a difference based on the firstview, the second view, and the first file set, the computer systemtransfers the difference to the destination. The destination isconfigured to generate the first file set from the second file set andthe difference.

A fourth aspect of the present application involves a method oftransferring a file set from a source to a destination using a computersystem. The computer system receives a plurality of files, the fileshaving respective file sizes. The computer system categorizes theplurality of files into a plurality of categories according to theirrespective file sizes. The plurality of categories includes: a firstcategory of files having respective file sizes in a first file sizerange; and a second category of files having respective file sizes in asecond file size range, wherein the file sizes in the second file sizerange are smaller than the file sizes in the first file size range. Fora respective file in the first category of files, the computer systemidentifies a first version and a second version of the respective fileand generates a difference between the first version and the secondversion of the respective file in the first category based on a view ofthe first version and a view of the second version, the first versionbeing reconstructable from the second version and the difference. For aplurality of respective files in the second category of files, thecomputer system identifies a file aggregation of the plurality ofrespective files by combining the plurality of respective files into onefile such that the combined file have a file size in the first file sizerange. The computer system identifies a first version and a secondversion of the file aggregation and generates a difference between thefirst version and the second version of the file aggregation based on aview of the first version and a view of the second version. The fileaggregation comprises the plurality of respective files and the firstversion of the file aggregation is reconstructable from the secondversion of the file aggregation and the difference.

Various advantages of the present application are apparent in light ofthe descriptions below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a data transport network inaccordance with some embodiments.

FIG. 2 illustrates an example transmission of a file from a source to adestination in accordance with some embodiments.

FIG. 3 illustrates an example transmission of a file difference from asource to a destination in accordance with some embodiments.

FIG. 4 illustrates an example local differential compression procedurein accordance with some embodiments.

FIG. 5 illustrates an example remote differential compression procedurein accordance with some embodiments.

FIG. 6 illustrates an example of file versions divided into chunks inaccordance with some embodiments.

FIG. 7 illustrates an example iterative differential compressionprocedure in accordance with some embodiments.

FIG. 8 illustrates an example iterative differential compressionprocedure in accordance with some embodiments.

FIG. 9 illustrates an example iterative differential compressionprocedure in accordance with some embodiments.

FIG. 10 illustrates an example iterative differential compressionprocedure in accordance with some embodiments.

FIG. 11 illustrates a diagram of file sets to be synchronized afterevolving independently from the same original file set, in accordancewith some embodiments.

FIG. 12 illustrates a diagram of views of file sets in accordance withsome embodiments.

FIG. 13 illustrates an example file set synchronization process, inaccordance with some embodiments.

FIG. 14 illustrates an example of a mobile application upgrade use case,in accordance with some embodiments.

FIG. 15 illustrates an example file set differencing and updatingprocess, in accordance with some embodiments.

FIG. 16 illustrates an example file set local differential compressionprocess in accordance with some embodiments.

FIG. 17 illustrates an example file set local differential compressionprocess in accordance with some embodiments.

FIG. 18 illustrates an example workflow through a data transport systemin accordance with some embodiments.

FIG. 19 illustrates an example workflow through a data transport systemin accordance with some embodiments.

FIG. 20 illustrates an example file archival stream in accordance withsome embodiments.

FIG. 21 illustrates an example annexation of a small file in accordancewith some embodiments.

FIGS. 22A-22B illustrate example data transport platforms in accordancewith some embodiments.

FIG. 23 is a block diagram illustrating a file storage system inaccordance with some embodiments.

FIG. 24 is a block diagram illustrating a data transport system inaccordance with some embodiments.

FIGS. 25A-25B illustrate an example method of transporting files inaccordance with some embodiments.

FIG. 26 illustrates an example method of transporting files inaccordance with some embodiments.

FIG. 27 illustrates an example method of transporting files inaccordance with some embodiments.

FIGS. 28A-28C illustrate an example method of transporting files inaccordance with some embodiments.

Like reference numerals refer to corresponding parts throughout thedrawings.

DESCRIPTION OF EMBODIMENTS

Reference will now be made in detail to embodiments, examples of whichare illustrated in the embedded drawings. In the following detaileddescription, numerous specific details are set forth in order to providea thorough understanding of the subject matter represented herein. Butit will be apparent to one skilled in the art that the subject mattermay be practiced without these specific details. In other instances,well-known methods, procedures, components, and circuits have not beendescribed in detail so as not to unnecessarily obscure aspects of theembodiments.

Generally speaking, there are two approaches of designing an efficientfile transferring technology: (i) transferring less yet equivalent datathrough, e.g., differential compression and (ii) employing a filetransport acceleration protocol.

In this application, a new set of differential compression techniques isdescribed. They generate “difference” between either two individualfiles or between two file sets. A new concept called “VIEW” thatprovides an efficient abstract of an individual file or a file set isintroduced. This concept provides a framework for the differentialcompression techniques disclosed in the present application.

In some embodiments, there are many file transfer applications that maybenefit from the differential compression techniques disclosed in thepresent application:

-   -   remote backup;    -   file replication;    -   disaster recovery;    -   file distribution and publishing;    -   file sharing, exchanging, synchronizing for collaboration;    -   managed file transfer;    -   big data cloud migration;    -   WAFS: wide area file service;    -   software release and patch management; and    -   mobile app download and upgrade.

FIG. 1 illustrates a data transport network 100 in accordance with someembodiments. The data transport (or “data transfer”) network 100includes file storage systems 102 and 108, data transport systems 104and 106, and communication network(s) 110.

The file storage system 102, at the source side, stores the files to betransported to the destination side for storage at the file storagesystem 108. The data transport system 104 performs various operations onthe files to prepare the files for transport. In some embodiments, theoperations include differential compression techniques that compress thefiles into compressed files data of smaller size that is moreefficiently transported, further details of which are described below.In some embodiments, the data transport system 104 transmits the filesdata to the data transport system 106. This transportation process maybe initiated by either data transport system.

The file storage system 108, at the destination side, is the storagedestination for the files from the file storage system 102. The datatransports system 106 receives the compressed files data from the datatransport system 104. The data transport system 106 performs operationson the compressed files data that are analogues of the operationsperformed by the data transport system 104, in order to reconstitute orreconstruct the files from the files data. In some embodiments, the datatransport system 106 receives the files data from the data transportssystem 104 through the network 110. The data transport system 106 storesthe reconstituted files in the file storage system 108. In someembodiments, the operations performed by the data transports system 106include techniques to reconstitute or reconstruct the files fromdifferentially compressed files data; the operations reverse thedifferential compression of the files data performed by the datatransport system 104.

The network(s) 110 include any wired or wireless local area network(LAN) and/or wide area network (WAN), such as an intranet, an extranet,or the Internet. It is sufficient that the network 110 providescommunication capability between the source side and the destinationside, and more particularly communication capability between datatransports systems 104 and 106. In some embodiments, the files data aretransmitted from the data transport system 104 to the data transportsystem 106, through the network 110, using the UDP-based Data TransferProtocol (UDT).

In some other embodiments, the files data is transported from the sourceside to the destination side without going through the network 110. Forexample, the files data from the data transport system 104 are copied toa storage device (e.g., a hard disk, an optical disk, flash memory). Thestorage device is manually transported (e.g., delivery by car) to alocation where the data transport system 106 is accessible (e.g., thephysical location of the data transport system 106). The files data iscopied from the storage device into the data transport system 106. Thedata transport system 106 processes the files data from the storagedevice to reconstitute the files for storage into the file storagesystem 108.

In the description above, the file storage system 102 and the datatransport system 104 are designated as the source side, and the filestorage system 108 and the data transport system 106 are designated asthe destination side, in order to indicate the direction of datatransport for purposes of description. Of course, in actualimplementations, the systems in the source side can take on the role ofsystems in the destination side, and vice versa, depending on the actualsituation and circumstances and the operations being performed. Forexample, in a remote backup system, in a backup operation, files at abackup agent (source side) are transported to a remote storage server(destination side). In a restore operation, the sides are reversed;files at the remote storage server (source side) are transported to abackup agent (destination side).

Data Transport Using Differential Compression

Without differential compression technologies, a new version N of a file(or a set of files) is sent from a source (e.g., file storage system102) to a destination (e.g., file storage system 108) over a network(e.g., network 110) to replace an older version O of the file (or theolder version of the set of files), as shown in FIG. 2. For illustrativepurposes, the discussion below first addresses the transfer of a file.

In some embodiments, the two versions of a file are near-duplicates andthe difference between them is relatively small compared to the wholefile size. If a difference Δ between N and O can be determined, and thedifference Δ is transmitted to the destination instead of N in itsentirety, as shown in FIG. 3, bandwidth and time can be saved, amongother advantages.

In some embodiments, differential compression (which can also be called“de-duplication”) is the technique used to determine the differencesbetween two files or two versions of one file. In some embodiments,there are two atomic string edit operations used for differentialcompression techniques:

-   -   a COPY instruction is defined as COPY(srcOffset, destOffset,        size); and    -   an ADD instruction is defined as ADD(destOffset, size, data).

Using the two atomic operations, the difference between N and O can bedefined as a sequence of COPY and ADD string edit operations. Based onthis sequence of COPY and ADD string edit operations, the old version Oof a file can be converted into the new version N of the file; the newversion N can be reconstituted or reconstructed from the old version Oand the difference.

As shown in FIG. 4, a differential compression technique called localdifferential compression (LDC) includes two procedures:

-   -   a difference procedure performed at the source side identifies        differences between a reference file O and a target file N, and        encodes the differences into a difference Δ efficiently; and    -   a merge procedure performed at the destination side reconstructs        the target file N from O and Δ.

As shown in FIG. 5, another differential compression technique calledremote differential compression (RDC) is a client-server filesynchronization technique in which two files are synchronized bycommunication of the differences. In this case, the differences betweenthe two versions may need to be identified through real-timecommunication between the source and the destination because neitherside initially has information about the file at the other side.

Both LDC and RDC have their respective advantages and drawbacks. Forexample, while RDC is storage efficient, it takes more time whensynchronizing a file between the source side and the destination side.Although LDC calculates the differences offline, which saves thetransferring time, it needs more storage for saving the old versions.

In this application, iterative differential compression (IDC) isdisclosed that can effectively overcome some issues associated with LDCand RDC. IDC is based on file chunking algorithms that split a file intoa sequence of chunks. If two nearly duplicate versions of a file arechunked into two sequences of chunks separately, the two files shouldhave many chunks in common, as shown in FIG. 6 for example. In FIG. 6, Oand N have chunks A, B, C, D, and E in common. O has chunks F and I notin common with N, and N has chunks H and G not in common with O.

In some embodiments, cutting points between adjacent chunks are selectedby the following approach:

-   -   A hash function H(x) is constructed to hash the sub-string of a        file starting at the offset x with length w, where w is called        sliding window size. For example, the function H(x) may be        constructed as a rolling hash function such as a Karp-Rabin        function or Adler-32 or the like.    -   Given a position x in a given string T[1, . . . , L], H(x) is        calculated over the substring T[x, . . . , x+w−1].

Note that there are many techniques to select cutting points based on H.One simple example is to select a cutting point x by letting H(x)≡0 modp, where p is a predefined prime number, and it can be provedmathematically that it is the average chunk size. One selects thep-value according to the application which may require a range of chunksizes. For example, a p of around 1021 or 4093 can be selected, etc.

Assuming that a given file F is split into a sequence of chunks {c₁, c₂,. . . , c_(n)},

-   -   each chunk is assigned its MD5 hash (or SHA-1 hash) as the chunk        identifier or “chunk ID,” denoted by CID(C), and    -   the file F can be represented by a sequence of <CID, CPOS,        CSIZ>, where CPOS is the chunk offset and CSIZ is the chunk        size.

In other words, a view of the file F, which is a new way of expressing aparticular version of the file F, can be defined as:

V(F)={<CID(c ₁),CPOS(c ₁),CSIZ(c ₁)>,<CID(c ₂),CPOS(c ₂),CSIZ(c ₂)>, . .. ,<CID(c _(n)),CPOS(c _(n)),CSIZ(c _(n))>}.

In some embodiments, additional information such as file size, thenumber of chunks and etc., may be included into the view forcompleteness. But for simplicity and without loss of generality, thesimplified representation of the file F as V(F) as shown is used in thedescription below.

Assuming that V(O), V(N) and N (but not O) are available at the sourceside (e.g., at file storage system 102), V(O) and V(N) can be used togenerate a sequence of COPY/ADD operations that convert the file from Oto N. For example, the COPY and ADD instructions involving chunks can bewritten as:

-   -   a COPY instruction is written as COPY(srcOffset, destOffset,        chunkSize); and    -   an ADD instruction is written as ADD(destOffset, chunkSize,        chunkData).

For the sequence of COPY and ADD operations generated from V(O) andV(N), for ADD operations the chunkData parameter is initially NIL. ThechunkData for the ADD operations are then filled with data from N. Assuch, the IDC from V(O) to N includes:

-   -   A difference procedure DIFF(V(O), N) is a procedure at the        source side (e.g., at the data transport system 104) that        generates Δ and V(N) from V(O) and N, which can be denoted as        <Δ, V(N)>=DIFF(V(O), N), and includes the following steps:        -   a. create the view V(N) from N: N→V(N);        -   b. generate a sequence of COPY/ADD operations from <V(N),            V(O)>:            -   i. COPY(V(O)::CPOS(c), V(N)::CPOS(c), V(N)::CSIZ(c))                where c is a chunk common to O and N; and            -   ii. ADD(V(N)::CPOS(d), V(N)::CSIZ(d), NIL) where d is a                chunk in N only; and        -   c. for each ADD operation, set chunkData=N[V(N)::CPOS(d),            V(N)::CSIZ(d)−1].    -   A merge procedure MERGE(O, Δ) is a procedure at the destination        side (e.g., at the data transport system 106) that reconstructs        the file N from O and Δ, denoted as N=MERGE(O, Δ), or N=O+Δ.

In some embodiments, there is a sequence of versions of a file F thatneed to be transferred from the source side to the destination side overthe network in a timely manner (e.g., between different data centerssupporting the same application). For the sequence {F₁, F₂, . . . ,F_(n)}, the IDC can be performed iteratively as follows:

-   -   Send F₁ to the destination.    -   Generate difference Δ₂ between F₂ and F₁. Send difference Δ₂ to        the destination. Reconstruct F₂=F₁+Δ₂ at the destination.    -   . . .    -   Generate difference Δ_(n) between F_(n-1) and F₁. Send        difference Δ_(n) to the destination and reconstruct        F_(n)=F_(n-1)+Δ_(n) at destination.

As shown in FIG. 7, when applying the VIEW concept, this iterativeprocess can be elaborated as follows:

-   -   a. at the source side, start with an initial O at the source        side by creating V(O) from O and sending O to the destination        side;    -   b. at the source side, where O has been updated to N, set <V(N),        Δ>=DIFF(V(O), N);    -   c. transfer Δ to the destination side (e.g., to data transport        system 106). In some embodiments, Δ is transmitted from the        source side to the destination side through the network 110. In        some other embodiments, other methods are used, such as physical        delivery;    -   d. at the destination side (e.g., at data transport system 106),        let N=MERGE(O, Δ) (and N is stored in the file storage system        108); and    -   e. at the source side (e.g., at the file storage system 102),        set V(O)=V(N) and wait for next N and return to step b.

In some embodiments, IDC may be used for sending updates from one sourceto multiple destinations that may contain different previous versions ofthe current file as shown in FIG. 8. In this case, the source side mayneed to prepare multiple differences Δ based on the current version ofthe file at different destinations.

In some embodiments, as shown in FIG. 9, the IDC procedure can beextended from differencing of a single file to differencing of a fileset based on the same chunk-based techniques described above. In thiscase, a view represents a file set including one or more files. Assumingthat a given file F in a file set is split into a sequence of chunks{c₁, c₂, . . . , c_(k)}:

-   -   Assign each chunk its MD5 hash as the chunk ID, denoted by        CID(c);    -   Define the file set using the two tables Tables 1 and 2 below:        Tables 1 and 2, which provide an efficient VIEW to represent a        file set S, denoted as V(S);        -   a. Table 1 represents each file with a file ID, its path and            a sequence of chunks for each file, where each chunk is            represented by a chunk ID;

TABLE 1 File Path (Path from the relative File ID root + file name)Sequence of Chunk IDs FID₁ PATH₁ { CID¹ ₁, CID¹ ₂, . . . , CID¹ _(k) } .. . . . . . . . FID_(p) PATH_(p) { CID^(p) ₁, CID^(p) ₂, . . . , CID^(p)_(s)}

-   -   -   b. Table 2 defines each chunk with an ID, its size and a            sequence of its first occurrence in each file that contains            the chunk. The occurrence is represented by the file ID and            the chunk offset.

TABLE 2 Chunk ID Chunk Size Chunk Information CID₁ CSIZ₁ {< FID¹ ₁,CPOS¹ ₁>, . . . , < FID¹ _(z), CPOS¹ _(z)>} . . . . . . . . . CID_(q)CSIZ_(q) {< FID^(q) ₁, CPOS^(q) ₁>, . . . , < FID^(q) _(t), CPOS^(q)_(t)>}

When a file set O is updated, it becomes a new file set N. File setchanges includes three types of files:

-   -   A—a subset of new files added into the file set N.    -   D—a subset of files deleted from the file set O.    -   U—a subset of files updated from file set O to file set N.

The file set level IDC from O to N includes:

-   -   A difference procedure DIFF( . . . ) at the source side (e.g.,        at data transport system 104), which is a procedure that        generates Δ and V(N) from V(O), A, U, D and N. The procedure can        be denoted as <Δ, V(N)>=DIFF(V(O), A, U, D, N) and includes the        following steps:        -   a. Generate Table 3 below and Table 2 above from <A, U, D>.            Tables 2 and 3 form the view V(A, U, D) for <A, U, D>.

TABLE 3 File ID File Path Sequence of Chunk IDs Type (A/U/D) FID₁ PATH₁{ CID¹ ₁, CID¹ ₂, . . . , CID¹ _(k) } A . . . . . . . . . FID_(p)PATH_(p) { CID^(p) ₁, CID^(p) ₂, . . . , CID^(p) _(s)} D

-   -   -   b. For each chunk c in Table 2:            -   i. If c is not an existing chunk in V(O), add it to                Table 4 below with <CID, CSIZ> and then look at the                <FID, CPOS> in Table 2 to copy CDATA from a file with                the FID of N into Table 4 below.

TABLE 4 Chunk ID Chunk Size Chunk Data CID₁ CSIZ₁ CDATA₁ . . . . . . . .. CID_(q) CSIZ_(q) CDATA_(q)

-   -   -   -   ii. If c already exists in V(O) and it is associated                with the file type D, remove the item from the <FID,                CPOS> sequence of chunk information for CID in Table 2,                and if the chunk information sequence for CID in Table 2                becomes NIL, remove the record from Table 2 for CID. In                other words, V(A, U, D) is being modified.

        -   c. Set Δ=<V(A, U, D), Table 4>;

        -   d. Construct V(N) from V(O) and V(A, U, D), i.e., <V(O),            V(A, U, D)>→V(N). For each FID in Table 3:            -   i. For type A—Add this record to V(O)::Table 1.            -   ii. For type U—Replace the sequence from Table 1 with                the sequence from Table 3.            -   iii. For type D—Delete the record from Table 1 with the                same FID. For any associated chunk CID that does not                belong to any FID, remove the record with CID from                V(O)::Table 2.

        -   e. Set V(N) when step d is completed.

    -   A merge procedure MERGE(O, Δ) at destination, which is a        procedure to reconstruct the file N from O and Δ, denoted as        N=MERGE(O, Δ), or N=O+Δ        -   a. For each FID in V(A, U, D)::Table 3:            -   i. Type D—with the PATH, delete the file in place;            -   ii. Type U—use the record from V(A, U, D)::Table 3, V(A,                U, D)::Table 2 and Table 4 to reconstruct the file that                may copy the chunk from the old file in place or get                CDATA from Table 4.            -   iii. Type A—use the record from V(A, U, D)::Table 3,                V(A, U, D)::Table 2 and Table 4 to construct a new file                that may copy the chunk from an old file or get CDATA                from Table 4.        -   b. After step a, let N=MERGE(O, Δ), also denoted as N=O+Δ.

Note that the DIFF procedure creates V(N) from V(O) and V(A, U, D)instead of N itself, thus making the process more efficient. As show inFIG. 9, the process of updating a file set has four phases. At thesource side, the system notifies all file changes from O to N (e.g., thefile storage system 102 notifies data transports system 104). Thechanges include adding new files (A), file modifications (U) and filedeletions (D) which are represented by (A, U, D). The system then usesthe differential compression (or de-duplication) process to generate Δfrom O and N and transfer Δ over the network to the destination. Asnoted above, transferring Δ can be performed, for example, over thenetwork (e.g., network 110) or performed manually (e.g., by physicaldelivery of a storage device containing Δ). At the destination, thesystem performs the MERGE procedure that constructs N from O and Δ.

The description above describes Tables 1-4 and operations performed withrespect to these tables. It should be appreciated that the references toTables 1-4 above are for ease of description and understanding. Inactual implementations, the operations are performed with respect torespective data structures corresponding to these tables in therespective views.

In some embodiments, the file set level IDC can handle the one source &multiple destinations update, as shown in FIG. 10. In FIG. 10,respective differences are determined depending on the current versionof the file set S at the respective destinations. Thus, a respectivedestination gets the appropriate respective difference forreconstructing the current version of S from the respective differenceand the version of S that is at the destination.

In some embodiments, in the data transport system 100 (FIG. 1) andfollowing the examples described above with reference to FIGS. 8-10, atthe source side, the files (or file sets) (e.g., the new versions) arestored in the file storage system 102. The data transport system 104includes the modules (e.g., DIFF engine) for determining differences, aswell as views of files (or of file sets). The views themselves arestored in the file storage system 102 or in the data transport system104. The data transport system 104 is notified of changes to files (orto file sets) in the file storage system 102. The data transport system104 uses the changes (e.g., <A, U, D>) to ultimately determine thedifference that is transported to the destination side. At thedestination side, the data transport system 106 includes the modules(e.g., MERGE module or engine) that reconstruct the new versions offiles (and of file sets) from the old versions and the differences. Thereconstructed new versions are stored in the file storage system 108.

In some embodiments, there is a need to synchronize two sets of filesacross the network when one set has no knowledge of the other one. Forexample, the two sets of files may evolve from the same set as shown inFIG. 11.

The concept of VIEW of a file set can be used for file setsynchronization as well. First, the file set synchronization problem canbe defined as two similar file sets R and T at two ends of the networkas shown in FIG. 12. Their views V(R) and V(T) are available and updatedto be current.

In some embodiments, as shown in FIG. 13, the file set synchronizationis performed as the following steps:

-   -   a. V(R) was sent from the destination side to the source side,        where we have <T, V(T)>;    -   b. Use a difference procedure DIFF(V(R), V(T), T) to generate Δ:        -   i. Use V(R), V(T) to create a sequence of COPY/ADD            operations.        -   ii. Use T to fill the chunk data for each ADD operation in            the sequence.    -   c. Send Δ to the destination side;    -   d. Perform a merge procedure MERGE(R, Δ) at the destination side        to reconstruct the file set T from R and Δ, denoted as        T=MERGE(R, Δ), or T=R+Δ.

In some embodiments, the data transferring for V(R) and Δ can be doneusing a UDP-based file transport protocol.

In some embodiments, in the data transport system 100 (FIG. 1) andfollowing the examples described above with reference to FIGS. 11-13, atthe source side, the files (or file sets) (e.g., T in FIG. 13) arestored in the file storage system 102. The data transport system 104includes the modules (e.g., a DIFF module) for receiving the views ofthe files (or of the file sets) at the destination side (e.g., V(R) inFIG. 13) and determining differences, as well as views of files (or offile sets). The views themselves are stored in the file storage system102 or in the data transport system 104. The data transport system 104uses the view of the files (or of the file sets) at the destination(e.g., V(R)) and the files (or the file sets) at the source and theviews thereof (e.g., T and V(T)) to ultimately determine the differencethat is to be transported to the destination side. At the destinationside, the data transport system 106 includes the modules (e.g., a MERGEmodule) that reconstruct the desired files (and file sets) (e.g., T)from the files (and the file sets) at the destination (e.g., R) and thedifferences. The reconstructed files (and file sets) are stored in thefile storage system 108.

In some embodiments, there are many versions of a file set at onelocation and one needs to send different versions of the file set overthe network for file updating purposes. One example is upgrading ofmobile application software as shown in FIG. 14.

Traditional approaches to file set updating incorporate a tree modelthat presents hierarchical structures of file directories. Two file sets(e.g., an old version and a new version of a file set) can be presentedas respective trees of files, for example. There is a one-to-one mappingbetween two sets of files that maps each node on the tree correspondingto one file set to a node on the tree corresponding to the other fileset based on heuristic rules. The heuristics rules include, for example,that the pair of nodes (either files or directories) have the same name,and that the parent nodes of both nodes are mapped.

In the traditional approach, the procedure for determining thedifferences includes applying LDC to mapped node pairs one by one. If anode in the tree corresponding to the new version of the file set has nomapped node, that whole node is encoded without applying anydifferential compression because it is deemed to a new addition to thefile set.

FIG. 15 illustrates an example implementation of a file set leveldifferencing and updating. In FIG. 15, a difference Δ between file setsS₂ and S₁ is determined at the source side. The Δ is sent to thedestination, where file set S₂ is reconstructed from S₁ and Δ at thedestination side.

As shown in FIGS. 16 and 17, using the VIEW of a file set, the file setLDC can be performed as following steps:

-   -   At the source side:        -   i. Create V(S₁) from S₁ and save V(S₁) if V(S₁) does not            exist yet;        -   ii. Create V(S₂) from S₂ and save it V(S₂);        -   iii. Use the difference procedure DIFF(V(S₁), V(S₂), S₂) to            calculate A;        -   iv. Send the difference Δ to the destination side;    -   At the destination side:        -   i. Perform a merge procedure MERGE(S₁, Δ) to reconstruct the            file set S₂ from S₁ and Δ, denoted as S₂=MERGE(S₁, Δ), or            S₂=S₁+Δ.

In some embodiments, LDC techniques are performed for two individualfiles or for two file sets, each including multiple files, using abyte-level differential compression algorithm. A byte-level approach fortwo individual files has the following features:

-   -   The difference between two files is expressed in the form of a        sequence of COPY/ADD edit operations;    -   The difference algorithms identify common sub-strings between        two files which actually create a sequence of COPY operations;    -   The ADD operations can be derived from the COPY sequence.

In some embodiments, the byte-level approach provides fine graindifferential compression and often has a better compression rate.Assuming that a fingerprint generation procedure FG(F) is performed fora given file F, the byte-level approach for two file sets can beperformed as follows:

-   -   For a first file set S₁, a set of fingerprints for files in the        file set S₁ is generated and each file is assigned a unique file        ID. A first fingerprint database FPDB1 including the set of        fingerprints is created.    -   For files in a second file set S₂, the fingerprint generation        procedure FG(F) is invoked to generate a set of fingerprints and        index them into a second fingerprint database FPDB2        sequentially:        -   For each file f in S₂, fingerprints off are generated.            -   FPDB2 is searched for matches to fingerprints in FPDB1                to determine whether there exists a previously indexed                file g in FGDB1 such that f and g are nearly duplicated;            -   If yes, a byte-level difference engine (e.g., xdelta) is                used to generate the difference δ=f−g;            -   Otherwise, the fingerprints in FPDB2 are used to match                fingerprints in FPDB1 to determine whether there exists                a file F from S₁ that matches fin terms of                near-duplication. If yes, the difference δ=f−F is                generated; otherwise f is encoded as a new file using                one or more fingerprints and the fingerprints are                indexed into FPDB2.    -   Encode all δ+new files+other metadata into a whole difference        package Δ.

In some other embodiments, for the two file sets S₁ and S₂, both V(S₁)and V(S2) are generated, and then the following operations areperformed:

-   -   For each file node in S₂, the nearest duplicate node in S₁ is        identified if the number of common chunks presented by V(S₁) and        V(S₂) exceeds a predefined threshold. Otherwise, the file node        in S₂ is deemed to be a new node;    -   For each pair of nodes, the LDC approach is applied to calculate        the difference between the two file nodes in the pair.    -   Encode the whole difference as Δ.

In some embodiments, in the data transport system 100 (FIG. 1) andfollowing the examples described above with reference to FIGS. 15-17, atthe source side, the files (or file sets) (e.g., S₁ and S₂) are storedin the file storage system 102. The data transport system 104 includesthe modules (e.g., a DIFF module) for determining differences, as wellas views of files (or of file sets). The views themselves are stored inthe file storage system 102 or in the data transport system 104. Thedata transport system 104 uses the view of the files (or of the filesets) (e.g., V(S₁) and V(S₂)) and the files (or file sets) at the source(e.g., S₁ and S₂) to ultimately determine the difference that istransported to the destination side. At the destination side, the datatransport system 106 includes the modules (e.g., a MERGE module) thatreconstruct the desired files (or file sets) (e.g., S₂) from the files(or the file sets) at the destination (e.g., S₁) and the differences.The reconstructed files (or file sets) are stored in the file storagesystem 108.

FIG. 18 illustrates a file processing workflow 1800 at the source sidein accordance with some embodiments. The differential compressiontechniques described above may be performed by workflow 1800. Files tobe transported to the destinations side are stored at the file storagesystem 102. A file retriever module 1802 at the data transport system104 retrieves the files to be transported from the file storage system102. The file retriever 1802 passes the files to a dedupe engine ormodule 1804, which performs the differential compression techniquesdescribed above to determine the views and the differences. The viewsmay be stored in the data transport system 104 and/or in the filestorage system 102. The differences data is passed onto an assemblermodule 1806, which assembles the differences data into one or more datapackages (e.g., the differences data and corresponding metadata)suitable for transport to the destination side. A sender module 1808sends the data packages to the network 110 en route to the destinationside (e.g., to data transport system 106).

In some embodiments, the files at the source side are categorizedaccording to their file sizes before file differences are determinedFiles vary by size, and handling them all in the same way regardless ofsize may lead to waste of resources (e.g., bandwidth, processing power).By categorizing the files according to size, so that files of a certainsize range are handled one way and files of another size range arehandled another way, resources may be used more efficiently.

In some embodiments, the files are categorized into four categoriesbased on file size. Each category corresponds to a defined size range.For example, a “tiny files” category corresponds to files (“tiny” files)having a size smaller than 4 KB, a “small files” category corresponds tofiles (“small” files) having a size between 4 KB and 512 KB, a “normalfiles” category corresponds to files (“normal” files) having a sizebetween 512 KB and 2 GB, and a “large files” category corresponds tofiles (“large” files) having a size of 2 GB or larger. Files in the“tiny files” category are transported to the destination side as is;differential compression techniques are not applied to these files. Thedifferential compression techniques described above are applied to thefiles in the “normal files” category as they are. A file in the “largefiles” category is divided into segments of up to a defined maximum size(e.g., a file size in the “normal files” category, such as 256 MB), andthe differential compression techniques described above are applied toeach segment as if each file segment is an individual file in the“normal files” category. Files in the “small files” category are groupedtogether to create a group of files whose total file size is in anothercategory (e.g., the “normal files” category), and the group is processedas if the group is a file in another category. For example, if thegroup's total size corresponds to the “normal files” category, such as256 MB, the group is treated as if the group is a file in the “normalfiles” category.

It should be appreciated that the file size categories described aboveand the corresponding file size ranges are merely exemplary. More orless categories, as well as different size ranges for the respectivecategories, are possible.

FIG. 19 illustrates a file processing workflow 1900 at the source sidein accordance with some embodiments. The differential compressiontechniques described above, combined with categorization of files byfile size, may be performed by workflow 1900. Files to be transported tothe destinations side are stored at the file storage system 102. Anarchiving module 1910 collects the files into an archival stream (e.g.,a stream in the tar archive format). A file retriever module 1901 at thedata transport system 104 retrieves the archival streams from the filestorage system 102. The file retriever 1901 passes the archival streamsto a stream handler module 1902, which categorizes the files containedwithin the archival streams according to file size and processes thefiles accordingly.

The stream handler 1902 passes files in the “tiny files” categorydirectly to an assembler module 1906. The stream handler 1902 passesfiles in the “normal files” category as is to a dedupe engine or module104. The stream handler divides files in the “large files” category intosegments and passes the segments to the dedupe engine 1904. The streamhandler groups files in the “small files” category into groups andpasses the groups to the dedupe engine 1904. The dedupe engine 1904determines views and differences data for the files, segments, andgroups. The views may be stored in the data transport system 104 and/orin the file storage system 102. The differences data is passed onto anassembler module 1906, which assembles the differences data and thefiles in the “tiny files” category into one or more data packages (e.g.,the differences data and corresponding metadata, files and correspondingmetadata) suitable for transport to the destination side. A sendermodule 1908 sends the data packages to the network 110 en route to thedestination side (e.g., to data transport system 106).

As described above, files may be retrieved from the file storage system102 as an archival stream. As shown in FIG. 20, an archival stream is asequence of blocks, where the block size is 512 bytes. Each file takesone or more consecutive blocks:

-   -   If file size is less than or equal to 512 bytes, the file takes        up one block;    -   If 512*m<file size≦512*(m+1), the file occupies (m+1) blocks.

Two files do not share a block. Thus, if a block is not filled up by asingle file, the block is filled with padding bytes 2002.

The stream handler 1902 processes the files in the streams according totheir sizes as follows:

-   -   A file in the “tiny files” category is sent to the next process        (e.g., assembler module 1906) directly.    -   A file in the “normal files” category is sent to the dedupe        engine 1904 for de-duplication.    -   A file in the “large file” category is split it into a sequence        of segments, each with a predefined size corresponding to the        “normal files” category (e.g., 256 MB), with the last segment        for the file having a size less than or equal to the predefined        size. Alternatively, the segment size is defined per file so        that the file is divided into approximately equally sized        segments. Then the segments are sent to the dedupe engine 1904        for de-duplication.    -   A file in the “small files” category is picked from the stream,        and the stream handler 1902 waits for the next “small file,” and        so on. The “small files” are annexed together (as shown in        FIG. 21) into a group, and the group is sent to the dedupe        engine 1902 for de-duplication.

In some embodiments, the chunk sizes vary depending on the differentialcompression technique used. For example, for the updating (FIGS. 7-10)and syncing (FIGS. 11-13) techniques, chunk sizes can be relativelylarge (e.g., 1 KB, 4 KB or even larger). For the differencing technique(FIGS. 14-17), the chunk sizes are relatively smaller (e.g., 31, 61, or91 bytes).

In some embodiments, a unified data transport platform is built on topof the differential compression techniques described above, as shown inFIG. 22A, to support the applications described above (e.g., remotebackup, file replication, disaster recovery, etc.). For example, theupdate module 2202 corresponds to the differential compressiontechniques described above with reference to FIGS. 7-10. The sync module2204 corresponds to the differential compression techniques describedabove with reference to FIGS. 11-13. The delta module 2204 correspondsto the differential compression techniques described above withreference to FIGS. 14-17.

FIG. 22B shows the unified data transport platform built on top of thedifferential compression techniques described above, as in FIG. 22A, butwith an additional stream module 2208, on top of which the update module2202, sync module 2204, and delta module 2206 can be built. The streammodule 2208 handles the retrieval of archival streams from the filestorage system and categorizing of files by size as described above withreference to FIGS. 19-21.

FIG. 23 is a block diagram illustrating a file storage system 102/108 inaccordance with some embodiments. The file storage system 102/108typically includes one or more processing units (CPU's) 2302, one ormore network or other communications interfaces 2304, memory 2306, andone or more communication buses 2308 for interconnecting thesecomponents. The communication buses 2308 optionally include circuitry(sometimes called a chipset) that interconnects and controlscommunications between system components. Memory 2306 includeshigh-speed random access memory, such as DRAM, SRAM, DDR RAM or otherrandom access solid state memory devices; and may include non-volatilememory, such as one or more magnetic disk storage devices, optical diskstorage devices, flash memory devices, or other non-volatile solid statestorage devices. Memory 2306 may optionally include one or more storagedevices remotely located from the CPU(s) 2302. Memory 2306, includingthe non-volatile and volatile memory device(s) within memory 2306,comprises a non-transitory computer readable storage medium. In someembodiments, memory 2306 or the non-transitory computer readable storagemedium of memory 2306 stores the following programs, modules and datastructures, or a subset thereof, including an operation system 2310, anetwork communication module 2312, files 2314, and an archival streamingmodule 2320.

The operating system 2310 includes procedures for handling various basicsystem services and for performing hardware dependent tasks.

The network communication module 2312 facilitates communication withother systems via the one or more communication network interfaces 2304(wired or wireless) and one or more communication networks, such as theInternet, other wide area networks, local area networks, metropolitanarea networks, and so on.

The files 2314 are files stored at the file storage system 102/108.Files 2314 are transported from a source-side file storage system 102 toa destination-side file storage system 108, and replace at the filestorage system 108 older or different versions of the files. In someembodiments, the files are grouped into, and processed as, file sets ofmultiple files.

The file storage system 102/108 also includes views 2316 of the files2314. A view 2316 defines a file as a sequence of chunks, as describedabove.

Changes 2318 track changes in the files 2314. Changes 2318 includerecords of new files, updated files, and deleted files. Changes 2318 arereported to the data transport system 104.

Archival streaming module 2320 packages files or file sets 2314 asarchival streams (e.g., stream in a tar format), which are sent to thedata transport system 104/106.

Each of the above identified elements may be stored in one or more ofthe previously mentioned memory devices, and each of the modules orprograms corresponds to a set of instructions for performing a functiondescribed above. The set of instructions can be executed by one or moreprocessors (e.g., the CPUs 2302). The above identified modules orprograms need not be implemented as separate software programs,procedures or modules, and thus various subsets of these modules may becombined or otherwise re-arranged in various embodiments. In someembodiments, memory 2306 may store a subset of the modules and datastructures identified above. Furthermore, memory 2306 may storeadditional modules and data structures not described above.

Although FIG. 23 shows a file storage system, FIG. 23 is intended moreas functional description of the various features which may be presentin a file storage system than as a structural schematic of theembodiments described herein. In practice, and as recognized by those ofordinary skill in the art, items shown separately could be combined andsome items could be separated. For example, some items (e.g., operatingsystem 2310 and network communication module 2312 shown separately inFIG. 23 could be implemented on single servers and single items could beimplemented by one or more servers. The actual number of servers andstorage devices used to implement the file storage system 102/108 andhow features are allocated among them will vary from one embodiment toanother, and may depend in part on the amount of data traffic that thesystem must handle during peak usage periods as well as during averageusage periods.

FIG. 24 is a block diagram illustrating a data transport system 104/106in accordance with some embodiments. The data transport system 104/106typically includes one or more processing units (CPU's) 2402, one ormore network or other communications interfaces 2404, memory 2406, andone or more communication buses 2408 for interconnecting thesecomponents. The communication buses 2408 optionally include circuitry(sometimes called a chipset) that interconnects and controlscommunications between system components. Memory 2406 includeshigh-speed random access memory, such as DRAM, SRAM, DDR RAM or otherrandom access solid state memory devices; and may include non-volatilememory, such as one or more magnetic disk storage devices, optical diskstorage devices, flash memory devices, or other non-volatile solid statestorage devices. Memory 2406 may optionally include one or more storagedevices remotely located from the CPU(s) 2402. Memory 2406, includingthe non-volatile and volatile memory device(s) within memory 2406,comprises a non-transitory computer readable storage medium. In someembodiments, memory 2406 or the non-transitory computer readable storagemedium of memory 2406 stores the following programs, modules and datastructures, or a subset thereof, including an operation system 2410, anetwork communication module 2412, de-duplication module 2414, fileretriever module 2420, stream handler module 2422, assembler module2426, sender module 2428, merge module 2430, and optionally views 2432.

The operating system 2410 includes procedures for handling various basicsystem services and for performing hardware dependent tasks.

The network communication module 2412 facilitates communication withother systems via the one or more communication network interfaces 2404(wired or wireless) and one or more communication networks, such as theInternet, other wide area networks, local area networks, metropolitanarea networks, and so on.

The de-duplication module 2414 applies differential compression (e.g.,the differential compression techniques described above) to files andfile sets. The de-duplication module 2414 includes a view module 2416for generating the views of files and file sets, and a difference module2418 for determining the difference between files and between file sets.

The file retriever module 2420 retrieves files 2314 (as files, filesets, or archival streams) and views 2316 from the file storage system102/108.

The stream handler module 2422 processes archival streams retrieved fromthe file storage system 102/108. In some embodiments, the stream handlermodule 2422 includes a file categorization module 2424 that categorizesfiles according to size, in order that the files are processed accordingto size.

The assembler module 2426 assembles difference data generated by thede-duplication module 2414 and optionally other data, and packages thedata into data packages for transport.

The sender module 2428 sends the data packages to the opposite datatransport system (e.g., data transport system at the source side to thedata transport system at the destination side). In some embodiments, thesender module 2428 includes an implementation of a data transportprotocol (e.g., UDP-based Data Transfer Protocol) used for transportingthe data packages.

Merge module 2430 performs the merge operations in order to reconstructthe files and file sets being sent from the source side from the filesor file sets to be replaced and the difference data from the sourceside. The merge module 2430 also sends the reconstructed files or filesets to the file storage system in the destination side.

In some embodiments, views 2432 of files and of file sets, generated aspart of the differential compression process, are stored in the datatransport system 104/106.

Each of the above identified elements may be stored in one or more ofthe previously mentioned memory devices, and each of the modules orprograms corresponds to a set of instructions for performing a functiondescribed above. The set of instructions can be executed by one or moreprocessors (e.g., the CPUs 2402). The above identified modules orprograms need not be implemented as separate software programs,procedures or modules, and thus various subsets of these modules may becombined or otherwise re-arranged in various embodiments. In someembodiments, memory 2406 may store a subset of the modules and datastructures identified above. Furthermore, memory 2406 may storeadditional modules and data structures not described above.

Although FIG. 24 shows a file storage system, FIG. 24 is intended moreas functional description of the various features which may be presentin a file storage system than as a structural schematic of theembodiments described herein. In practice, and as recognized by those ofordinary skill in the art, items shown separately could be combined andsome items could be separated. For example, some items (e.g., operatingsystem 2410 and network communication module 2412 shown separately inFIG. 24 could be implemented on single servers and single items could beimplemented by one or more servers. The actual number of servers andstorage devices used to implement the data transport system 104/106 andhow features are allocated among them will vary from one embodiment toanother, and may depend in part on the amount of data traffic that thesystem must handle during peak usage periods as well as during averageusage periods.

FIGS. 25A-25B illustrates an example method of transporting files inaccordance with some embodiments. The method is performed at a computersystem with memory and one or more processors (e.g., data transportsystem 104 and file storage system 102).

A first version of a file set of a plurality of files is identified(2502). For example, with reference to FIG. 9 above, the new version Nof a file set is identified. The new version N is stored in the filestorage system 102 and is retrieved from the file storage system 102 bythe data transport system 104.

One or more file set changes from a second version of the file set tothe first version of the file set are identified (2504). The file setchanges include at least one of: one or more added files, one or moreupdated files, and one or more deleted files. The changes from an oldversion O of the file set to the new version N are identified. Thechanges <A, U, D> specify the files added (A), files updated (U), andfiles deleted (D) when O changed to N. In some embodiments, the datatransport system 104 is notified of the changes <A, U, D> from O to Nperiodically or as the changes are made.

A view of the first version of the file set is generated based on a viewof the second version of the file set and the identified file setchanges (2508). A view V(N) of the new version N is generated based on aview V(O) of the old version O and a view V(A, U, D) of the file setchanges <A, U, D>. In some embodiments, as described above withreference to FIG. 9, V(N) is generated by modifying V(O) based on V(A,U, D).

In some implementations, prior to generating the view of the firstversion of the file set and the difference, the view of the file setchanges is generated, where the view of the file set changes include aplurality of entries, each entry corresponding to a respective chunk inone of a respective added file, a respective updated file, or arespective deleted file (2506). Before generating V(N) based on V(O) andV(A, U, D), V(A, U, D) is generated from <A, U, D>. V(A, U, D) includesdata structures corresponding to Tables 2 and 3 described above. Table 3includes entries for respective files in <A, U, D>, includingidentifiers of chunks for the respective files. Table 2 includes entriesfor chunks in the files included in Table 3. Thus, V(A, U, D) includesentries for respective chunks in added files, updated files, and/ordeleted files.

In some embodiments, the view of the second version of the file set isstored at a storage location (2510). V(O) is stored in the file storagesystem 102 and/or the data transport system 104.

In some embodiments, generating a view of the first version of the fileset based on a view of the second version of the file set and a view ofthe file set changes includes modifying the view of the second versionof the file set based on the view of the file set changes (2512). Asdescribed above, V(N) is generated from V(O) and V(A, U, D). thisgeneration includes modifying, within V(O) the data structurescorresponding to Table 1 and Table 2 based on entries in V(A, U, D),such as adding entries corresponding to added files into V(O)::Table 1and so on.

A difference between the first version of the file set and the secondversion of the file set is generated based on the view of the file setchanges (2514). A difference Δ is generated from V(A, U, D) and Table 4,as described above. The difference Δ is a representation of thedifference between O and N, in a view-based formatted as describedabove.

In some embodiments, generating a difference based on the view of thefile set changes includes associating data corresponding to the addedfiles and the updated files with the view of the file set changes(2516). In some embodiments, the data corresponding to the added filesand the updated files includes respective chunks in the added files andthe updated files (2518). In some embodiments, the data corresponding tothe added files and the updated files are derived from the first versionof the file set (2520). As described above, the difference Δ isgenerated based on V(A, U, D) and Table 4. Table 4 includes entries forchunks not already in O and V(O) (e.g., chunks from added files, updatedchunks from updated files). Chunk data for the chunks not already in Oand V(O) are copied from N into Table 4.

The difference is transferred to a destination having the second versionof the file set, where the destination is configured to generate thefirst version of the file set from the second version of the file setand the difference (2522). The data transport system 104 transports thedifference Δ (e.g., through network 110) to the data transport system106 on the destination side. The data transport system 106 is configuredto perform a merge operation on the difference Δ and O to reconstruct N,which is stored in the file storage system 108.

In some embodiments, the view of the second version of the file set isreplaced at the storage location with the view of the first version ofthe file set (2524). Back at the source side, the generated V(N)replaces V(O) in wherever V(O) is stored; because N becomes the oldversion of the file set as N is changed (e.g., to N′), V(N) takes theplace of V(O) as V(N′) takes the place of V(N).

FIG. 26 illustrates an example method of transporting files inaccordance with some embodiments. The method is performed at a computersystem with memory and one or more processors (e.g., data transportsystem 104 and file storage system 102).

A first file set of a first plurality of files is identified (2602).Referring to the description of FIGS. 11-13 above, at the source side, afile set T is identified. The data transport system 102 retrieves thefile set T from the file storage system 102.

A first view of the first file set is generated (2604). A V(T) isgenerated at the source side (e.g., by the data transport system 104).

A second view of a second file set of a second plurality of files isreceived from a destination (2606). The source side (e.g., the datatransport system 104) receives a V(R) of a file set R from thedestination side, where R is stored (e.g., in the file storage system108). The V(R) is generated by the destination side (e.g., the datatransport system 106).

A difference is generated based on the first view, the second view, andthe first file set (2608). The data transport system 102 generates adifference Δ based on V(T), V(R), and T. The difference Δ is arepresentation of the difference between T and R.

In some embodiments, generating a difference based on the first view,the second view, and the first file set includes determining a sequenceof operations based on the first view and the second view, the sequenceof operations including one or more copy operations and one or more addoperations (2610), identifying, from the first file set, datacorresponding to the add operations (2614), and associating the datacorresponding to the add operations with the sequence of operations(2616). Generating the difference Δ includes determining a sequence ofCOPY and ADD operations based on V(T) and V(R), identifying data (e.g.,chunks of files) in T and not in R (and thus are the data to be added bythe ADD operations), and associating the data with the difference A. Asdescribed above, the data transport system 104 uses V(T) and V(R) todetermine a sequence of COPY and ADD operations, and fills the dataparameters in the ADD operations with chunk data from T. The result ofthese steps is the difference Δ.

In some embodiments, determining the sequence of operations includescomparing the first view and the second view (2612). The data transportsystem 102 compares V(T) and V(R) to determine which file chunks arecommon to both views and which file chunks are in V(T) but not in V(R).Based on this comparison, the sequence of COPY and ADD operations isdetermined.

The difference is transferred to the destination, where the destinationis configured to generate the first file set from the second file setand the difference (2618). The data transport system 104 transports thedifference Δ (e.g., through network 110) to the data transport system106 on the destination side. The data transport system 106 is configuredto perform a merge operation on the difference Δ and R to reconstruct T,which is stored in the file storage system 108.

FIG. 27 illustrates an example method of transporting files inaccordance with some embodiments. The method is performed at a computersystem with memory and one or more processors (e.g., data transportsystem 104 and file storage system 102).

A first file set of a first plurality of files and a second file set ofa second plurality of files are identified (2702). Referring to thedescription of FIGS. 14-17 above, at the source side, file sets S₁ andS₂ are identified. The data transport system 102 retrieves the file setsS₁ and S₂ from the file storage system 102.

A first view of the first file set and a second view of the second fileset are generated (2704). The data transport system 104 generates viewsV(S₁) and V(S₂).

A difference is generated based on the first view, the second view, andthe first file set (2706). The data transport system 102 generates adifference Δ based on V(S₂), V(S₁), and S₂. The difference Δ is arepresentation of the difference between S₁ and S₂.

In some embodiments, generating a difference based on the first view,the second view, and the first file set includes determining a sequenceof operations based on the first view and the second view, the sequenceof operations including one or more copy operations and one or more addoperations (2708), identifying, from the first file set, datacorresponding to the add operations (2712), and associating the datacorresponding to the add operations with the sequence of operations(2714). Generating the difference Δ includes determining a sequence ofCOPY and ADD operations based on V(S₂) and V(S₁), identifying data(e.g., chunks of files) in S₂ and not in S₁ (and thus are the data to beadded by the ADD operations), and associating the data with thedifference Δ. The data transport system 104 uses V(S₂) and V(S₁) todetermine a sequence of COPY and ADD operations, and fills the dataparameters in the ADD operations with chunk data from S₂, similar to theprocedure for determining the difference in FIGS. 11-13. The result ofthese steps is the difference A.

In some embodiments, determining the sequence of operations includescomparing the first view and the second view (2710). The data transportsystem 102 compares V(S₂) and V(S₁) to determine which file chunks arecommon to both views and which file chunks are in V(S₂) but not inV(S₁). Based on this comparison, the sequence of COPY and ADD operationsis determined.

The difference is transferred to the destination, where the destinationis configured to generate the first file set from the second file setand the difference (2618). The data transport system 104 transports thedifference Δ (e.g., through network 110) to the data transport system106 on the destination side. The data transport system 106 is configuredto perform a merge operation on the difference Δ and S₁ to reconstructS₂, which is stored in the file storage system 108.

FIGS. 28A-28C illustrate an example method of transporting files inaccordance with some embodiments. The method is performed at a computersystem with memory and one or more processors (e.g., data transportsystem 104 and file storage system 102).

A plurality of files is received (2802). The files have respective filesizes ranging from “tiny” (e.g., smaller than 4 KB) to “large” (e.g., 2GB or larger). The files are stored at the file storage system 102. Thefiles are received by the data transport system 104. The files may besent to the data transport system 104 as archival streams.

The plurality of files is categorized into a plurality of categoriesaccording to their respective file sizes (2804). The plurality ofcategories include a first category of files having respective filesizes in a first file size range, and a second category of files havingrespective file sizes in a second file size range, wherein the filesizes in the second file size range are smaller than the file sizes inthe first file size range. The data transport system 104 (e.g., the filecategorization module 2424) categorizes the files by size. In someembodiments, there are a “tiny files” category, a “small files”category, a “normal files” category, and a “large files” category. The“normal files” category corresponds to a file size range (e.g., 512 KB-2GB), and the “small files” category corresponds to a file size range ofsmaller file sizes than the “normal files” category (e.g., 4 KB-512 KB).As shown in FIG. 19, files are processed differently based on the filesize category.

For a respective file in the first category of files (2806), a firstversion and a second version of the respective file are identified(2808), and a difference between the first version and the secondversion of the respective file in the first category is generated basedon a view of the first version and a view of the second version, wherethe first version is reconstructable from the second version and thedifference (2810). For example, for a file in the “normal files”category, the differential compression techniques described above areapplied to the file: a difference between a first version and a secondversion of the file (e.g., a new version N and an old version O of thefile) is determined based on views of the first and second versions(e.g., V(N) and V(O)). The difference is determined such that N isreconstructable from O and the difference (e.g., by a merge operationN=O+difference) The difference is transported to the data transportsystem 106 on the destination size, where the merge operation isperformed to reconstruct N. Similarly, the differential compressiontechniques described above are applied to the file sets of “normal”files.

For a plurality of respective files in the second category of files(2812): a file aggregation of the plurality of respective files isidentified by combining the plurality of respective files into one filesuch that the combined file have a file size in the first file sizerange (2814), a first version and a second version of the fileaggregation are identified (2816), and a difference between the firstversion and the second version of the file aggregation is generatedbased on a view of the first version and a view of the second version,where the file aggregation includes the plurality of respective files,wherein the first version of the file aggregation is reconstructablefrom the second version of the file aggregation and the difference(2820). Files in the “small files” category are annexed into a largerfile group or aggregation (e.g., into one file). The size of the filegroup or aggregation is that of one of the other categoriescorresponding to larger file sizes (e.g., a size in the “normal files”range). A first version (e.g., a new version) and a second version(e.g., an old version) of the file aggregation are identified, and viewsare generated for the first and second versions. A difference betweenthe first version and the second version is generated based on theviews, such that the first version can be reconstructed from a mergeoperation on the second version and the difference. Thus, the filegroup/aggregation is treated as if it is a file in the “normal files”category. In some embodiments, the differential compression techniquesdescribed above are applied to file sets that contain file aggregations,as if the file sets contain “normal” files.

In some embodiments, the first version of the file aggregation includesrespective first versions of the plurality of respective files, and thesecond version of the file aggregation includes respective secondversions of the plurality of respective files (2818). The first versionof the file aggregation includes respective first versions (e.g.,respective new versions) of the individual files in the fileaggregation, and the second version of the file aggregation includesrespective second versions (e.g., respective old versions) of theindividual files in the file aggregation.

In some embodiments, the plurality of categories include a thirdcategory of files having respective file sizes in a third file sizerange, where the file sizes in the third file size range are larger thanthe file sizes in the first file size range (2822). For a respectivefile in the third category of files, the respective file is divided intoa plurality of segments (2824), each file segment having a file size inthe first file size range, respective first versions and second versionsof each of the plurality of segments are identified (2826), and for arespective segment, a difference between a first version of therespective segment and a second of the respective segment is generatedbased on a view of the first version of the segment and a view of thesecond version of the segment, where the first version of the segment isreconstructable from the second version of the segment and thedifference (2828). For example, a file in the “large files” category isdivided into segments. In some embodiments, the segment for a file eachhas a size that is in the “normal files” category, except for perhapsthe last segment. For each segment, a first version and a second versionare identified. In some embodiments, each respective segment isidentified in a first version of the file and a second version of thefile. For a respective segment, say, a Segment A, Segment A in the firstversion of the file is the first version of Segment A, and Segment A inthe second version of the file is the second version of Segment A.Respective views are generated for the first version and the secondversion of Segment A. A difference between the first version and thesecond version is generated based on the views, such that the firstversion of Segment A can be reconstructed from a merge operation on thesecond version of Segment A and the difference. Thus, each segment istreated as if it is a file in the “normal files” category. In someembodiments, the differential compression techniques described above areapplied to file sets that contain the segments, as if the file setscontain “normal” files.

As described above, files in the “small files” category are grouped intoaggregations that are treated as files in the “normal files” category,and segments of files in the “large files” category are treated as filesin the “normal files” category. In some embodiments, the categorizationof files according to file size, grouping of “small” files, andsegmenting of “large” files are transparent to the module(s) applyingthe differential compression techniques (e.g., dedupe engine 1904,de-duplication module 2414). From the perspective of these modules,whatever data is received as inputs for the differential compression,whether they are “normal” files, aggregations of “small” files, orsegments of “large” files, the modules treat them all as “normal” filesand are unaware of the categorization. Similarly, the modules treat filesets containing “normal” files, file sets containing aggregations of“small” files, and file sets containing segments of “large” files all asfile sets of “normal” files without being aware of the categorization.

While particular embodiments are described above, it will be understoodit is not intended to limit the invention to these particularembodiments. On the contrary, the invention includes alternatives,modifications and equivalents that are within the spirit and scope ofthe appended claims. Numerous specific details are set forth in order toprovide a thorough understanding of the subject matter representedherein. But it will be apparent to one of ordinary skill in the art thatthe subject matter may be practiced without these specific details. Inother instances, well-known methods, procedures, components, andcircuits have not been described in detail so as not to unnecessarilyobscure aspects of the embodiments.

The terminology used in the description of the invention herein is forthe purpose of describing particular embodiments only and is notintended to be limiting of the invention. As used in the description ofthe invention and the appended claims, the singular forms “a,” “an,” and“the” are intended to include the plural forms as well, unless thecontext clearly indicates otherwise. It will also be understood that theterm “and/or” as used herein refers to and encompasses any and allpossible combinations of one or more of the associated listed items. Itwill be further understood that the terms “includes,” “including,”“comprises,” and/or “comprising,” when used in this specification,specify the presence of stated features, operations, elements, and/orcomponents, but do not preclude the presence or addition of one or moreother features, operations, elements, components, and/or groups thereof.

As used herein, the term “if” may be construed to mean “when” or “upon”or “in response to determining” or “in accordance with a determination”or “in response to detecting,” that a stated condition precedent istrue, depending on the context. Similarly, the phrase “if it isdetermined [that a stated condition precedent is true]” or “if [a statedcondition precedent is true]” or “when [a stated condition precedent istrue]” may be construed to mean “upon determining” or “in response todetermining” or “in accordance with a determination” or “upon detecting”or “in response to detecting” that the stated condition precedent istrue, depending on the context.

Although some of the various drawings illustrate a number of logicalstages in a particular order, stages that are not order dependent may bereordered and other stages may be combined or broken out. While somereordering or other groupings are specifically mentioned, others will beobvious to those of ordinary skill in the art and so do not represent anexhaustive list of alternatives. Moreover, it should be recognized thatthe stages could be implemented in hardware, firmware, software or anycombination thereof.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theembodiments were chosen and described in order to best explain theprinciples of the invention and its practical applications, to therebyenable others skilled in the art to best utilize the invention andvarious embodiments with various modifications as are suited to theparticular use contemplated.

What is claimed is:
 1. A computer-implemented method, comprising: at acomputer system having one or more processors and memory storingprograms executed by the one or more processors, identifying a firstversion of a file set of a plurality of files; identifying one or morefile set changes from a second version of the file set to the firstversion of the file set, the file set changes comprising at least oneof: one or more added files, one or more updated files, and one or moredeleted files; generating a view of the first version of the file setbased on a view of the second version of the file set and the identifiedfile set changes; generating a difference between the first version ofthe file set and the second version of the file set based on the view ofthe file set changes; and transferring the difference to a destinationhaving the second version of the file set, wherein the destination isconfigured to generate the first version of the file set from the secondversion of the file set and the difference.
 2. The method of claim 1,wherein the view of the second version of the file set is stored at astorage location.
 3. The method of claim 2, further comprising:replacing the view of the second version of the file set at the storagelocation with the view of the first version of the file set.
 4. Themethod of claim 1, wherein generating a view of the first version of thefile set based on a view of the second version of the file set and aview of the file set changes comprises: modifying the view of the secondversion of the file set based on the view of the file set changes. 5.The method of claim 1, further comprising: prior to generating the viewof the first version of the file set and the difference, generating theview of the file set changes, wherein the view of the file set changescomprises a plurality of entries, each entry corresponding to arespective chunk in one of a respective added file, a respective updatedfile, or a respective deleted file.
 6. The method of claim 1, whereingenerating a difference based on the view of the file set changescomprises associating data corresponding to the added files and theupdated files with the view of the file set changes.
 7. The method ofclaim 6, wherein the data corresponding to the added files and theupdated files comprises respective chunks in the added files and theupdated files.
 8. The method of claim 6, wherein the data correspondingto the added files and the updated files are derived from the firstversion of the file set.
 9. A computer system, comprising: one or moreprocessors; memory; and a plurality of program modules stored in thememory and executed by the one or more processors, the program modulesfurther including instructions for: identifying a first version of afile set of a plurality of files; identifying one or more file setchanges from a second version of the file set to the first version ofthe file set, the file set changes comprising at least one of: one ormore added files, one or more updated files, and one or more deletedfiles; generating a view of the first version of the file set based on aview of the second version of the file set and the identified file setchanges; generating a difference between the first version of the fileset and the second version of the file set based on the view of the fileset changes; and transferring the difference to a destination having thesecond version of the file set, wherein the destination is configured togenerate the first version of the file set from the second version ofthe file set and the difference.
 10. The computer system of claim 9,wherein the view of the second version of the file set is stored at astorage location.
 11. The computer system of claim 10, wherein theprogram modules further include instructions for replacing the view ofthe second version of the file set at the storage location with the viewof the first version of the file set.
 12. The computer system of claim9, wherein the instruction for generating a view of the first version ofthe file set based on a view of the second version of the file set and aview of the file set changes further includes instructions for modifyingthe view of the second version of the file set based on the view of thefile set changes.
 13. The computer system of claim 9, wherein theprogram modules further include instructions for: prior to generatingthe view of the first version of the file set and the difference,generating the view of the file set changes, wherein the view of thefile set changes comprises a plurality of entries, each entrycorresponding to a respective chunk in one of a respective added file, arespective updated file, or a respective deleted file.
 14. The computersystem of claim 9, wherein the instruction for generating a differencebased on the view of the file set changes further includes instructionsfor associating data corresponding to the added files and the updatedfiles with the view of the file set changes.
 15. The computer system ofclaim 14, wherein the data corresponding to the added files and theupdated files comprises respective chunks in the added files and theupdated files.
 16. The computer system of claim 14, wherein the datacorresponding to the added files and the updated files are derived fromthe first version of the file set.
 17. A non-transitory computerreadable storage medium, storing one or more program modules forexecution by one or more processors of a computer system, the one ormore program modules further including instructions for: identifying afirst version of a file set of a plurality of files; identifying one ormore file set changes from a second version of the file set to the firstversion of the file set, the file set changes comprising at least oneof: one or more added files, one or more updated files, and one or moredeleted files; generating a view of the first version of the file setbased on a view of the second version of the file set and the identifiedfile set changes; generating a difference between the first version ofthe file set and the second version of the file set based on the view ofthe file set changes; and transferring the difference to a destinationhaving the second version of the file set, wherein the destination isconfigured to generate the first version of the file set from the secondversion of the file set and the difference.
 18. The non-transitorycomputer readable storage medium of claim 17, wherein the instructionfor generating a view of the first version of the file set based on aview of the second version of the file set and a view of the file setchanges further includes instructions for modifying the view of thesecond version of the file set based on the view of the file setchanges.
 19. The non-transitory computer readable storage medium ofclaim 17, wherein the program modules further include instructions for:prior to generating the view of the first version of the file set andthe difference, generating the view of the file set changes, wherein theview of the file set changes comprises a plurality of entries, eachentry corresponding to a respective chunk in one of a respective addedfile, a respective updated file, or a respective deleted file.
 20. Thenon-transitory computer readable storage medium of claim 17, wherein theinstruction for generating a difference based on the view of the fileset changes further includes instructions for associating datacorresponding to the added files and the updated files with the view ofthe file set changes.